Problem

The consumer-side drain checks (take!, take!(ch, output), wait, and iterate) read the head/tail indices, observed an empty buffer, and then separately read the closed flag.

Although close() is ordered after every put!, the empty-snapshot read and the closed read are distinct atomic operations. So a producer's final put! can become visible to the consumer only after its close():

1. consumer reads head → sees empty (old value)
2. producer advances head (publishes item), then sets closed = true
3. consumer reads closed → sees true
4. consumer concludes closed-and-empty → throws / ends iteration → drops the last item

This surfaces as a rare (~0.1%) data-loss flake under load — e.g. a tee/pipeline consumer receiving fewer items than were produced.

Fix

Re-read the indices after observing closed. Because close() is ordered after every put!, a re-read at that point observes all published items, so a throw only happens when the channel is genuinely drained:

if ch.closed[] && tail == ch.head[]   # re-read head after seeing closed
    check_closed_and_throw(ch)
end

Applied to take!, take!(ch, output), and wait. Also simplified iterate to always attempt the (now race-free) take! rather than guarding it with the racy isopen(ch) || isready(ch) snapshot — take! already drains before throwing and check_closed_and_throw propagates bound-task exceptions.

Testing

Added a threaded regression test: produce N items, close(), then iterate and assert all N are received, over many trials. It fails reliably on the old code and passes on the fixed code. Verified 0 failures over 60,000 additional stress trials (iterate + take! paths) locally with --threads=4.

🤖 Generated with Claude Code